home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20000114-20000217
/
000148_news@columbia.edu _Wed Jan 26 13:27:59 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2000-02-16
|
2KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA25732
for <kermit.misc@watsun.cc.columbia.edu>; Wed, 26 Jan 2000 13:27:59 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id NAA23335
for kermit.misc@watsun.cc.columbia.edu; Wed, 26 Jan 2000 13:09:57 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: Case Study #10: Atomic File Movement
Message-ID: <gSF8krj$2SXn@cc.usu.edu>
Date: 26 Jan 00 10:51:36 MDT
Organization: Utah State University
To: kermit.misc@columbia.edu
> By the way, what makes Kermit somewhat immune to the two-armies problem,
> also known as the three-way-handshake problem, is that the Z packet and
> its ACK are not the final stage of Kermit protocol; the file receiver does
> exit the protocol or close the connection after acknowledging the Z
> packet. In fact, the whole protocol is protected by an "outer layer" that
> has no consequences at the file level. If this outer layer is disturbed
> at the end (in the typical case, by premature disconnection) there might
> be an annoying delay, but no harm is done.
>
> - Frank
---------
A "friendly amendment." While the Kermit protocol, and TCP, do an
acceptable job of confirming stages of work are completed, those techniques
do not remove ambiguity. Frank correctly states "somewhat immune." Old
packets whose sequence numbers have wrapped to the proper current value,
badly garbled ones with apparently legit contents (CRC checks are hardly
perfect), and packets delivered by mistake to the wrong session, are three
serious concerns for protocol designers because they confuse the normal
stage by stage confirmations. TCP uses three way handshakes, extra steps
to extend sequence numbers in some circumstances, and pseudo headers, to
help reduce false indications. Kermit does a pretty good job too, but not
to the extent that TCP goes.
The two hill army problem remains when one gets serious about comms.
As stated, there is no certainty in the exchange, only approximation to it.
Joe D.